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Status of this Memo 
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not specify an Internet standard of any kind. Distribution of this 
memo is unlimited. 
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Abstract 


This document discusses the applicability of Constraint-—Based LSP 
Setup using LDP. It discusses possible network applications, 
extensions to Label Distribution Protocol (LDP) required to implement 
constraint-—based routing, guidelines for deployment and known 
limitations of the protocol. This document is a prerequisite to 
advancing CR-LDP on the standards track. 


1. Introduction 


As the Internet evolves, additional capabilities are required to 
ensure proper treatment of data [3], voice, video and other delay 
sensitive traffic [4]. MPLS enhances source routing and allows for 
certain techniques, used in circuit switching, in IP networks. This 
permits a scalable approach to handling these diverse transmission 
requirements. CR-LDP [1] is a simple, scalable, open, non- 
proprietary, traffic engineering signaling protocol for MPLS IP 
networks. 


CR-LDP provides mechanisms for establishing explicitly routed Label 


Switched Paths (LSPs). These mechanisms are defined as extensions to 
LDP [2]. Because LDP is a peer-to-peer protocol based on the 
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establishment and maintenance of TCP sessions, the following natural 
benefits exist: 


CR-LDP messages are reliably delivered by the underlying TCP, and 
State information associated with explicitly routed LSPs does not 
require periodic refresh. 


CR-LDP messages are flow controlled (throttled) through TCP. 


CR-LDP is defined for the specific purpose of establishing and 
maintaining explicitly routed LSPs. Additional optional capabilities 
included have minimal impact on system performance and requirements 
when not in use for a specific explicitly routed LSP. Optional 
capabilities provide for negotiation of LSP services and traffic 
management parameters over and above best-effort packet delivery 
including bandwidth allocation, setup and holding priorities. CR-LDP 
optionally allows these parameters to be dynamically modified without 
disruption of the operational (in-service) LSP [4]. 


CR-LDP allows the specification of a set of parameters to be signaled 
along with the LSP setup request. Moreover, the network can be 
provisioned with a set of edge traffic conditioning functions (which 
could include marking, metering, policing and shaping). This set of 
parameters along with the specification of edge conditioning 
functions can be shown to be adequate and powerful enough to 
describe, characterize and parameterize a wide variety of QoS 
scenarios and services including IP differentiated services [5], 
integrated services [6], ATM service classes [7], and frame relay 
[8]. 


CR-LDP is designed to adequately support the various media types that 
MPLS was designed to support (ATM, FR, Ethernet, PPP, etc.). Hence, 
it will work equally well for Multi-service switched networks, router 
networks, or hybrid networks. 


This applicability statement does not preclude the use of other 
signaling and label distribution protocols for the traffic 
engineering application in MPLS based networks. Service providers 
are free to deploy whatever signaling protocol meets their needs. 


In particular CR-LDP and RSVP-TE [9] are two signaling protocols that 
perform similar functions in MPLS networks. There is currently no 
consensus on which protocol is technically superior. Therefore, 
network administrators should make a choice between the two based 
upon their needs and particular situation. Applicability of RSVP-TE 
is described in [10]. 
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2. Applicability of extensions to LDP 


To provide support of additional LSP services, CR-LDP extensions are 
defined in such a way as to be directly translatable to objects and 
messages used in other protocols defined to provide similar services 
[9]. Implementations can take advantage of this fact to: 


Setup LSPs for provision of an aggregate service associated with 
the services being provided via these other protocols. 


Directly translate protocol messages to provide services defined 
in a non-CR-LDP portion of the network. 


Describe, characterize and parameterize a wide variety of QoS 
scenarios and services including IP differentiated services, 
integrated services, ATM service classes, and frame relay. 


Steady state information required for proper maintenance of an LSP 
may be as little as 200 bytes or less. It is not unreasonable to 
anticipate that CR-LDP implementations may support in excess of one 
hundred thousand or one million LSPs switched through a single Label 
Switching Router (LSR) under fairly stable conditions. 


Because CR-LDP provides for low overhead per LSP - both in terms of 
needed state information and control traffic - CR-LDP is applicable 
in those portions of the Internet where very large numbers of LSPs 
may need to be switched at each LSR. An example of this would be 
large backbone networks using MPLS exclusively to transport very 
large numbers of traffic streams between a moderately large number of 
MPLS edge nodes. 


CR-LDP may also be applicable as a mediating service between networks 
providing similar service extensions using widely varying signaling 
models. 


3. Implementation and deployment considerations in relation to LDP 


LDP specifies the following label distribution and management modes 
(which can be combined in various logical ways described in LDP): 


Downstream On Demand label distribution 
Downstream Unsolicited label distribution 
Independent Label Distribution Control 
Ordered Label Distribution Control 
Conservative Label Retention Mode 

Liberal Label Retention Mode 


The applicability of LDP is described in [11]. 
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In networks where only Traffic Engineered LSPs are required, the CR- 
LDP implementation and deployment does NOT require all the 
functionality defined in the LDP specification. The basic Discovery, 
Session, and Notification messages are required. However, CR-LDP 
requires one specific combination of the label distribution modes: 


Downstream On Demand Ordered label distribution and 
conservative Label Retention Mode 


Although CR-LDP is defined as an extension to LDP, support for 
Downstream Unsolicited Label Advertisement and Independent Control 
modes is not required for support of Strict Explicit Routes. In 
addition, implementations of CR-LDP MAY be able to support Loose 
Explicit Routes via the use of ’Abstract Nodes’ and/or 'Hierarchical 
Explicit Routing’, without using LDP for hop-by-hop LSP setup. 


CR-LDP also includes support for loose explicit routes. Use of this 
capability allows the network operator to define an ’explicit path’ 
through portions of their network with imperfect knowledge of the 
entire network topology. Proper use of this capability may also 
allow CR-LDP implementations to inter-operate with ’vanilla’ LDP 
implementations - particularly if it is desired to set up an 
explicitly routed LSP for best-effort packet delivery via a loosely 
defined path. 


Finally, in networks where both Routing Protocol-driven LSPs (a.k.a. 
hop-by-hop LSPs) and Traffic Engineered LSPs are required, a single 
protocol (LDP, with the extensions defined in CR-LDP) can be used for 
both TE and Hop-by-Hop LSPs. New protocols do not have to be 
introduced in the network to provide TE-LSP signaling. 


4. Limitations 


CR-LDP specification only supports point-to-point LSPs. Multi- 
point-to-point and point-to-multi-point are for further study (FFS). 


CR-LDP specification only supports unidirectional LSP setup. Bi- 
directional LSP setup is FFS. 


CR-LDP specification only supports a unique label allocation per LSP 
setup. Multiple label allocations per LSP setup are FFS. 


5. Security Considerations 
No additional security issues are introduced in this document. As an 


extension to LDP, CR-LDP shares the security concerns associated with 
LDP. 
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9. Full Copyright Statement 
Copyright (C) The Internet Society (2002). All Rights Reserved. 


This document and translations of it may be copied and furnished to 
others, and derivative works that comment on or otherwise explain it 
or assist in its implementation may be prepared, copied, published 
and distributed, in whole or in part, without restriction of any 
kind, provided that the above copyright notice and this paragraph are 
included on all such copies and derivative works. However, this 
document itself may not be modified in any way, such as by removing 
the copyright notice or references to the Internet Society or other 
Internet organizations, except as needed for the purpose of 
developing Internet standards in which case the procedures for 
copyrights defined in the Internet Standards process must be 
followed, or as required to translate it into languages other than 
English. 


The limited permissions granted above are perpetual and will not be 
revoked by the Internet Society or its successors or assigns. 


This document and the information contained herein is provided on an 
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 
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